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Wright  Laboratory 

Wright  Patterson  AFB  OH  45433-6543 


ABSTRACT 

Tlie  engineering  design  issues  of  supportability  and  main¬ 
tainability  are  expanded  upon  so  that  interested  individuals 
can  understand  (i)  how  these  issues  impact  a  modern 
weapon  system,  (2)  what  impaci  the  lack  of  concern  for 
these  issues  is  having  on  today's  weapon  systems,  and  (3) 
how  these  issues  might  be  better  considered  and  imple¬ 
mented  in  future  weapon  system  designs. 

1.  INTRODUCTION 

The  planners  of  future  applications  for  avionics  software 
are  frequently  tasked  with  the  issues  of  supportability  and 
maintainability  of  this  software.  These  issues  are  often 
treated  as  unique  design  issues  which  await  break-through 
technologies  for  tlieir  implementation.  Oftentimes  they  are 
shoved  aside  (or  deprioritized)  in  preference  of  more  con¬ 
crete  and  understatKlable  concepts.  As  a  result,  poor  speci- 
ficatioas  for  supporting  and  maintaining  systems  are  gener¬ 
ated,  which  are  increasingly  costly  in  terms  of  the  weapon 
system 's  life-cycle. 

This  paper  addresses  those  people  involved  in  the  acquisi¬ 
tion,  logistic.^,  and  use  of  avionics  software  by  showing 
cases  of  avionics  software  supportability  and  maintainabili¬ 
ty  and  how  to  go  about  designing  it.  Section  1  is  an  intro¬ 
duction  of  the  material  in  this  paper.  Section  II  defines 
supportability  and  maintainability.  Section  III  gives  an 
idealistic  example  of  a  strongly  designed  supportable  and 
maintainable  futuristic  fighter.  Section  fV  reviews  the  state 
of  supportability  and  maintainability  today.  Section  V 
examines  the  new  field  of  Software  Engineering  and  how  it 
shoutd  be  focused  to  impact  designing  for  supportability 
and  maintainability.  Section  VI  reviews  the  engineering 
design  pn>cess  and  how  it  can  accommodate  supponability 
and  maintainability.  Sections  VII  and  VIII  apply  the  engi¬ 
neering  design  process  to  software  scenarios  and  show 
where  supportability  and  maintainability  should  be  consid- 
eied  in  their  designs.  Section  IX  gives  a  brief  summary  of 
this  paper. 


IL  SUPPORTABILITY  AND  MAINTAINABILITY 
DEFINED 

Supportability  (in  the  context  of  Avionics  Software)  is  the 
provision  of  sophisticated  equipment,  special  facilities,  and 
detailed  documentation  in  order  to  perfonn  maintainability. 
Maintainability  is  the  probability  that  a  failed  computer 
software  configuration  item  (CSCI)  can  be  repaired  in  a 
specified  amount  of  time  using  a  specified  set  of  resources 
[4]. 

m.  AN  IDEALIS-nC  EXAMPLE  OF  SUPPORTABLE 
AND  MAINTAINABLE 
AVIONICS  SOFTWARE 

Let’s  project  ourselves  into  the  year  2020  and  pretend  we 
have  the  management  responsibility  for  the  nation's  latest 
ALL-ENGAGEMENT  Fighter.  This  remarkable  aircraft 
can  fly  in  space  or  in  close  ground  support,  it  is  stealthy, 
and  it  has  a  new  impulse  propulsion  system  which  greatly 
reduces  its  fuel  requirements.  It  also  has  a  fully  integrated 
open  system  architecture  enabled  by  50  million  lines  of 
source  code. 

More  remarkable  than  this  system 's  haidware  features  and 
capabilities  is  the  built-in  design  for  system  supportability 
and  maintainability.  The  Fighter  is  accentuated  with 
redundant,  reconfigurable,  and  fault-tolerant  software 
which  provides  a  full  mission  software  report  tullowing 
each  sortie.  The  Fighter  is  also  arranged  so  that  it  can  be 
configured  as  a  simulator  with  the  capability  of  supporting 
any  level  of  testing,  including  sub-system  testing  and  full- 
up  integrated  testing  (air  or  ground).  Every  level  of  this 
Fighter’s  life-cycle  is  linked  by  a  network  of  interconnected 
media  which  enables  precise  and  traceable  documentation 
as  well  as  on-line  communication.  The  significance  of  this 
is  that  the  software  maintainer,  the  acquisition  specialist, 
and  the  pilot  have  a  perfect  flow  of  information  in  which 
they  can  report  problems,  specify  requirements,  lod  train 
each  other  through  a  common  media. 

Upon  close  examination  of  the  Fighter's  software,  we 
discover  more  amazing  design  features.  First  of  all,  there 


is  100%  source  code  compatibility  among  the  300  embed¬ 
ded  computers  on  the  Fighter.  These  300  embedded 
computers  are  written  in  Higher  Order  Language  (Ada 
2020)  and  are  facilitated  by  two  very  compatible  compilers. 
There  are  1500  Software  Modules  which  populate  the 
Operational  Flight  Programs  (OFPs)  of  the  300  embedded 
computers.  Of  these  1500  Modules,  40%  (600  Modules) 
are  common  among  the  embedded  computers  and  help 
encompass  the  Fighter’s  dynamically  rcconfigurable  re¬ 
sources.  Another  useful  design  feature  is  the  cmpha.sis  on 
reusable  code.  Thirty  percent  of  the  1500  Modules  (450 
Modules)  are  static  in  nature  and  can  be  used  over  and  over 
again  between  block  cycle  changes  and  between  other 
aircraft. 

Our  final  inve.stigation  is  of  the  Fighter’s  Software  Suppon 
Environment.  There  are  two  options  available  for  those 
concerned  with  changing  the  Fighter’s  300  OFPs.  The  first 
option  is  to  u.se  the  Fighter’s  built-in  capability,  which  is  a 
pull-dov/n  avionics  engineering  workstation.  Dynamic 
source  code  changes  can  be  made  directly  on  the  aircraft, 
with  the  aircraft  it.sclf  acting  as  the  integrator  and  fester. 
This  accommodates  battlefield  fixes  allowing  for  quick  re¬ 
sponse  times  and  emergency  repairs.  The  next  option  is  the 
more  fonnal  option  which  is  the  Centralized  Fleet  Sy.stem 
Support  Facility  (CFSSF)  wliich  is  able  to  maintain  atiy  of 
the  DoD’s  3000  OFPs.  In  both  options,  the  OFF  Module 
Mainlainer  u.ses  sophisticated  engineering  workstations 
which  dynamically  configure  the  required  resources  for  a 
given  change  requirement;  automatically  documents  any 
action:  creates  specialized  te.sting  for  the  changes;  inquires 
the  CFSSF  archives  for  documentation  and  software  related 
to  the  change  requirement  and  displays  this  data  on-line: 
and  builJs  loadable  OFPs. 

Note  that  the  originality  of  our  ALL-ENGAGEMENT 
Fighter  is  that  it  has  been  emphasized  in  its  design  to  be 
supportable  and  to  be  maintainable.  This  has  not  been  the 
case  with  today’s  weapon  systems  whose  supportability  and 
maintainability  have  been  developed  in  the  middle  of  their 
life  cycle  and  oftentimes  after  they  have  been  transitioned 
to  their  support  organizations. 

IV.  SUPPORTABLE  AND  MAINTAINABLE 
AVIONICS  SOFTWARE  TODAY 

Today’s  generation  of  weapon  systems  u.se.s  avionics  soft¬ 
ware  which  is  supported  and  whi  1  is  maintained.  But  is 
this  software  supportable?  and  is  it  maintainable?  The 
answer  to  these  questions  depends  on  what  is  considered 
acceptable  by  the  owner  of  the  weapon  system.  If  the 
owner  finds  acceptable  1 8  month  (or  longer)  block  cycle 
turn-over  times  and  increasingly  co.stly  avionics  integrated 
support  environments,  then  the  answer  to  both  is  yes.  But  if 


the  owner  faces  rapidly  ch;mging  threat  environments  and 
shrinking  budget  constraints,  the  answer  is  clearly  no. 

Today’s  typical  software  support  environment  is  the  Avion¬ 
ics  Integrated  Support  Facility  (AISF)  which  is  now  being 
called  the  Centralized  Software  Support  Activity  (CSSA). 
A  typical  AISF  can  maintain  5  to  10  OFPs.  Each  OFF 
requires  specialized  support  equipment,  most  of  which  is 
incompatible  with  the  other  OFPs’  .support  equipment. 
Each  OFP  also  requires  specially  trained  people  who  are 
generally  overloaded  with  the  workload  for  that  OFP  [6]. 

The  typical  avionics  software  OFP  should  be  reviewed  as 
far  as  its  maintainability.  Of  the  5  to  10  OFPs  which  are 
maintained  in  an  AISF,  each  has  its  unique  source  code 
(usually  assembler  language)  with  unique  support  utilities 
such  as  compilers  and  linkers.  In  order  to  integrate  two  or 
more  OFPs  together,  specialized  software  and  hardware 
has  to  be  developed  allowing  them  to  pass  information. 
Other  specialized  proccs.ses  include  documentation,  test¬ 
ing,  configuration  management,  and  training.  Given  our 
definition  of  maintainability  and  today's  increasingly  con- 
.stiained  AISFs,  the  probability  is  low  that  CSCIs  can  be 
repaired  in  a  timely  manner. 

The  situation  facing  today’s  avionics  software  maintenance 
organizations  is  that  they  will  manage  an  increasing  number 
of  OFPs  (20  and  up)  with  the  same  or  fewer  resources. 
Given  today's  .scenario  of  an  increasing  workload  and  with 
the  same  or  fewer  resources,  previous  design  considera¬ 
tions  for  supportability  and  maintainability  will  be  obsolete, 
if  they  aren’t  already  [2],[3],[5],[6]. 

V.  APPLYING  SOFTWARE  ENGINEERING 
DISCIPLINE  TO  OBTAIN  SUPPORTABLE  AND 
MAINTAINABLE  AVIONICS  SOFTWARE 

As  Software  Engineering  has  been  evolving,  two  camps 
have  emerged  as  the  champions  for  this  new  discipline. 
The  first  camp  has  been  largely  responsible  for  bringing 
Softw.-ue  Engineering  where  it  is  today.  This  is  the  Com¬ 
puter  Science  Camp.  Tlie  Computer  Science  Community 
has  effectively  responded  to  the  recent  challenges  of  the 
"Age  of  Automation"  which  include  an  ever  increasing 
appetite  for  software.  The  second  camp  is  responsible  for 
software  as  it  is  increasingly  utilized  in  systems  of  every 
type.  This  camp  i.s  the  Traditional  Engineering  Camp. 
Unfortunately,  the.se  camps  ha/e  been  less  than  coopera¬ 
tive.  The  Computer  Science  Camp  desires  Software  Engi¬ 
neering  to  be  a  more  creative  and  flexible  discipline  while 
t‘'c  Tratlitional  Engineering  Camp  would  like  to  see  Soft¬ 
ware  Engineering  stress  standards  which  would  enable 
software  lo  be  reliable,  supportable,  and  maintainable  for 
its  complex  systems.  Objectively,  Software  Engineering 


should  best  serve  both  camps.  It  should  be  creative  and 
flexible  enough  to  respond  to  new  challenges  while  also 
serving  the  existing  system’s  requirements.  The  existing 
software  requirements  of  today’s  Avionics  Systems  demand 
increasingly  complex  and  repeatable  solutions  for  mature 
weapon  .systems  platforms.  These  systems  are  not  easily 
receptive  to  new  technologies  because  they  have  been 
independently  developed  with  limited  concerns  to  their 
iong  term  support  requirements.  To  add  to  the  complexity 
of  these  .systems  is  their  diverse  support  environment  re¬ 
quirements  seen  in  the  increasing  demand  for  Avionics 
Integrated  Support  Facilities. 

VI.  THE  ENGINEERING  DESIGN  PROCESS 

The  design  process  is  a  systematic  flow  of  developing  an 
item  of  equipment  that  meets  a  predetermined  product 
specification.  The  basic  concept  for  any  design  process  is  a 
controlled  approach  to  translating  the  product  specification 
into  a  working  system  that  fulfills  the  need  of  the  user. 
While  products  of  the  design  process  can  be  anything 
imaginable,  the  basic  design  pro  .ss,  in  theory,  should  be 
identical.  The  design  process  is  a  series  of  coordinated 
activities  that  form  the  basis  for  all  activities  necessary  to 
produce  the  desired  item.  Tltc  design  process  must  integrate 
the  efforts  of  all  engineering  disciplines  to  ensure  that  the 
user’s  needs  and  requirements  are  met  by  the  final  product 
design  [4]. 

In  order  for  suppoitability  and  maintainability  to  be  includ¬ 
ed  in  the  design  process,  they  must  be  carefully  and  com¬ 
pletely  .specified  along  with  the  other  constraints  of  the 
system. 


VII.  APPLYING  THE  PROCESS  TO  A  SIMPLE 
SOFTWARE  PROBLEM 

Let’s  consider  the  ca.se  where  a  simple  software  program  is 
the  product  of  tlic  design  process.  The  series  of  coordinated 
activities  arc  those  specified  in  iVlIL-STD-2167A  |1]  which 
include  system  requirements  analy.sis  and  design,  software 
requirements  analysis,  preliminary  design,  detailed  design, 
coding  and  unit  test,  component  integration  and  testing, 
item  testing,  and  system  integration  and  testing.  Let’s  say 
this  software  runs  a  digital  clock  and  displays  the  clock’s 
output.  In  application  of  our  design  process,  the  system  ic- 
quirernents  analysis  and  design  tcll.s  us  we  need  an  .auto¬ 
mated  time  system.  The  software  requirements  analysis 
tells  us  wc  need  .software  to  run  a  digital  clock.  Tlie  prelim¬ 
inary  design  lay.-,  out  the  functionality  of  software,  its  test¬ 
ing  needs,  and  the  components  it  will  require.  The  detailed 
design  specifies  the  software  to  the  lowest  level  and  plans 
for  low  level  testing  as  well.  Component  integration  and 


testing  checks  our  low  level  design.  Item  testing  checks  out 
our  complete  software  design.  Finally  we  tiy  our  software 
out  in  its  digital  clock  by  performing  a  system  integration 
and  test  by  installing  and  running  it  [7].  Where  in  this  proc¬ 
ess  should  we  specify  the  desired  level  of  suppoitability  and 
maintainability?  Since  we  want  our  software  to  meet  a 
predetermined  level  of  both  supportability  and  maintain¬ 
ability,  we  must  clearly  lay  out  our  requirements  in  the 
system  requirements  analysis  and  design. 

Vm.  APPL’HNG  THE  PROCESS  T  O  A  COMPLEX 
AVIONICS  PROBLEM 

Taking  the  same  digital  clock  software,  we  will  apply  some 
requirements  which  will  make  it  much  more  complicated. 
These  include:  (1)  The  software  will  be  the  basic  timing 
lo.gic  for  a  modern  fighter  systems  fire  control  computer 
operational  flight  program.  (2)  The  .software  is  to  be 
modular  and  generic  so  that  it  can  be  used  in  multiple 
applications  including  other  weapon  system.s.  (3)  The 
software  will  be  field  changeable  in  24  hours  or  less.  (4) 
The  support  environment  for  changing  and  testing  this 
software  will  be  otally  commercial  off-the-shelf  (COTS) 
equipment  It  would  dc  foobsh  to  handle  these  requirements 
anywhere  but  up  front  in  our  design  proccs.s.  It  ha.s  been 
proven  [7]  that  software  support  and  maintenance  account 
for  70%  and  mote  of  the  overall  system  lifc-cycle  costs  . 

IX.  SUMMARY 

Increasingly,  the  cost  and  time  spent  in  developing  and 
operating  weapon  systems  is  found  in  those  systems’  soft¬ 
ware.  The  majority  of  the  .software  cost  and  time  .spent  is  in 
its  maintenance  .and  support.  Without  carefully  specifying 
the  requirements  for  suppoitability  and  maintainability 
during  system  requirements  analysis  and  design,  the  ability 
and  affordability  of  operating  a  weapon  system  becomes 
prohibitive.  TTie  engineering  design  process  already  exists. 
This  process,  when  properly  specified,  will  accommodate 
building  supportability  and  maintainability  as  weapon 
system  requirements, 
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